AWS特有の運用イベントまとめ（非障害系）

#AWS

中山順博

2018.03.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

中山（順）です

運用設計、やってますか？

運用設計を行うとき、運用する中でどんなイベントが発生するか想定し、その際に実施する作業手順を作成すると思います・・・してますよね？！

しかし、AWS特有の運用イベントは「実際に使ってみないとわからない」「使ってみてはじめて知った」というものが多いのではないでしょうか。

そこで、この記事ではAWSを運用する中で発生するイベントのうち、AWS特有のものをまとめてみました。

おことわり

AWS特有 の運用イベントをまとめたものになります。利用者がAWS上で構築したシステム、利用するアプリケーション、開発やデプロイ手法などに依存する（内的要因にもとづく）イベントは含んでいません。
障害系のイベントも今回のまとめには含んでいません。
主要なものを挙げておりますが、完全に網羅しているわけではありません。他にも重要なイベントがあれば是非コメントで補足をお願いします。

イベント／運用作業の分類

今回、運用イベントの発生タイミングやイベントに対応する作業の特性に応じて、以下の4種類の作業に分類しました。

定常作業
定時作業
申請作業
非定常作業
緊急作業
属人作業

この分類は、運用設計ラボの波田野氏の資料を参考にさせていただきました。

各作業の定義は、下記の資料のP41およびP43-46を参照してください。

運用組織論 /operation-organization by opelab

整理の仕方

各運用イベントに対して、以下の情報をまとめたいと思います。

関連サービス
イベント
求められる作業
その他

通知

通知は、主に以下の方法で行われます。

AWSアカウントのメールアドレスへのEメール
API(CLI/SDK)
Personal Health Dashboard
Management Console
(SNS Topic)

ほとんどのイベントはこれのいずれかで把握できるはずです。

このうち、Personal Health Dashboardについて少し補足します

Personal Health Dashboard

AWSではHealth APIが提供されており、Management ConsoleではこのAPIを使って各種の問題が発生していないか一覧できるダッシュボードが提供されています。弊社臼田の記事を参照していただければと思いますが、どんなイベントを確認できるかをAWS CLIの"describe-event-types"コマンドなどで確認できます。

AWS Health APIから取得できるイベントタイプを確認してみた

定時作業

まずは、定期的に発生するイベントです。

関連サービス	イベント	作業内容
ACM	証明書の有効期限切れ／自動更新失敗	証明書の手動更新
Route 53	ドメインの有効期限切れ	ドメインの手動更新
EC2/RDS etc	リザーブドの有効期限切れ	リザーブドインスタンスの購入
Trusted Advisor	メール通知	指摘事項の是正

【ACM】サーバー証明書の有効期限切れ／自動更新失敗

ACMは、CloudFrontとELBと連携してサーバー証明書を提供するサービスです。

ACMで発行する証明書は1年毎に更新する必要がありますが、基本的には自動更新されます。ただし、場合によっては自動更新が失敗するケースがあります。検証の仕組みは、以下のドキュメントを確認してください。

自動ドメイン検証の仕組み

自動検証に失敗した場合、EメールおよびPersonal Health Dashboardで通知されます。

自動検証に失敗した場合

また、外部で発行された証明書を利用している場合は、手動で更新する必要があります。再インポートの手順は、以下のドキュメントを参照してください。

証明書の再インポート

EV証明書が必要なケースでも無ければ、ACMで証明書を取得してオペレーションが発生しないようにしておきたいですね。

【Route 53】ドメインの有効期限切れ

Route 53は、独自ドメインの権威サーバーおよびドメインの取得サービスを提供します。

Route 53でドメインを取得した場合、1年毎に更新する必要がありますが、自動更新を無効化している場合には手動で更新する必要があります。有効期限の45日前にドメインの登録者の連絡先にEメールが送られます。忘れないように更新するか、自動更新を有効化しましょう。

ドメイン用に登録を更新する

【EC2/RDS etc】リザーブドの有効期限切れ

AWSにはリザーブドインスタンスという仕組みがあります。簡単に言うと、料金前払いしてもらう代わりにトータルで安くするよ！という仕組みです。

また、安くなるだけでなくインスタンスを確実に起動できるなどのアドバンテージもあります。（オンデマンドインスタンスの場合、AWS側のリソース不足でインスタンスを起動できないことが稀に発生します）

AWS Black Belt Online Seminar 2017 AWS のコスト最適化リザーブドインスタンス

リザーブドインスタンスは、1年もしくは3年分を購入できます。リザーブドインスタンスを継続して利用する場合には、追加購入が必要です。現時点で、自動更新等の機能は提供されておりません。マネージメントコンソールを確認し、買い忘れが無いように注意しましょう。

【Trusted Advisor】メール通知

Trusted Advisorは、各種設定がAWSのベストプラクティスに基づいて設定されているかをチェックし、問題があれば指摘してくれるサービスです。

具体的な指摘事項はこちらをご覧ください。

Trusted Advisor Best Practices (Checks)

Trusted Advisorでは通知設定を行うことで週に1回チェック結果をメールで受信することができます。これをトリガーに是正作業を行ってもいいでしょうし、月一で決まった日に是正を実施するのもよいでしょう。組織や体制によっても実施できる頻度は変わってくると思いますので、無理のない頻度で行いましょう。ただし、セキュリティに関するチェックだけでもできるだけ高頻度で実施することをおすすめします。

また、指摘された事項を全て是正する必要はありません。是正が必要かどうかは利用者が判断する必要があります。

例えば、「Amazon S3バケット許可」については推奨アクションとして以下のような記載があります。

推奨アクション バケットでオープンアクセスが許可する場合、オープンアクセスが本当に必要かどうか判断してください。必要ない場合は、バケットのアクセス許可を更新して、所有者または特定のユーザーのみにアクセスを制限します。「バケットとオブジェクトのアクセス許可の設定」をご覧ください。

当然ながら、必要だから公開しているS3バケットもあれば意図せずに公開されているバケットもあると思います。その判断は利用者の責任で行ってください。 導入時に設計資料を作成して残しておけば、判断できますよね？

申請作業

次に申請作業です。

関連サービス	イベント	作業内容
ELB	キャンペーンやメディアでの紹介など、システムへの大量アクセスが想定	暖機申請
全般	負荷テストを実施	負荷テスト申請
全般	侵入テストを実施	侵入テスト申請
全般	リソース数などが上限に抵触	上限緩和申請

【ELB】暖機申請

ELBで利用できるCLBおよびALBは、負荷に応じて自動でスケールアウトしますが、負荷の上昇が急激な場合にスケールアウトが追いつかない場合があります。そのような急激な負荷の上昇が見込まれる場合（W◯S砲とか、Yah◯◯砲とか）、暖機申請を行うことで予めスケールアウトさせておくことが可能です。

Elastic Load Balancing の暖機申請について

負荷テスト申請

意外とご存じないケースがあるのですが、負荷テスト時にも申請が必要です。もし申請を行っていないと、テストのための通信が遮断されたり、テスト用のクライアント環境にAWSを利用している場合、不正利用と誤認されてアカウントがロックされる可能性があります。

余裕を持ったスケジュールを立てましょう。

Amazon EC2 テストポリシー（ネットワークストレステスト）

侵入テスト申請

こちらも負荷テストと目的は同じで、テスト用の通信の遮断やアカウントロックを防ぐために必要な申請です。

侵入テスト

上限緩和申請

1つのAWSアカウント上で作成できるリソースの数や、その中で可能な設定の数（アクセス制御のためのルールなど）は上限が決められています。それを超えて利用したい場合、上限緩和申請を行うことで上限値を増やすことが可能です。

AWS サービス制限

ただし、すべてのリソースに対して制限値を無限に緩和できるわけではありません。大規模な利用の場合、どこまで緩和した上でどこまで上限を増やせるか、確認しておくことをおすすめします。

緊急作業

関連サービス	イベント	作業内容
EC2	ホストのリタイアメント	インスタンスの再起動
RDS	緊急度の高いパッチのリリース	インスタンスの再起動
DirectConnect	緊急および計画的メンテナンス	-
VPC	VPN接続のメンテナンス	-
EC2	AMIのリリース	（例）Launch Configurationの再作成、設定

【EC2】ホストのリタイアメント

AWSの利用者は物理サーバーを意識することはほとんどありません。しかし、どこかの物理サーバー上で動いていることに変わりはありません。当然、古くなっていきますし、壊れることもあります。

AWSでは、物理ホストを退役させる際、そのホスト上でEC2インスタンを起動させている利用者に対して停止および起動を要求します。これを行うことで、EC2インスタンスは他の物理ホストへ移動します。（ライブマイグレーション、できるようにならないかなー）

ホストが退役する場合、"[Retirement Notification] Amazon EC2 Instance scheduled for retirement."などの件名でメールが送られてきます。メールの内容を確認し、EC2インスタンスを停止+起動させましょう。（「再起動」では稼働するホストが変わりません。）

詳細は、以下のドキュメントを参照してください。

インスタンスのリタイア

【RDS】緊急パッチのリリース

RDSはリレーショナルデータベースを提供するマネージドサービスです。

データベースエンジンやOSに重大な脆弱性が発見された場合、適用必須（強制適用）のパッチがリリースされることがあります。その際、インスタンス再起動が伴うため、予め組織内での調整やシステムの利用者への周知などを行う必要があるでしょう。

自動で適用する場合、RDSインスタンスに指定したMaintenance Windows内に適用されます。手動で適用する場合にはインスタンスの再起動を行うことでスケジュールされたメンテナンスが併せて実行されます。詳細は以下のドキュメントを参照してください。

Amazon RDS メンテナンス

Multi-AZ構成とすることで、メンテナンスの影響を軽減することが可能です。高い可用性を求める場合、メンテナンスによるシステム停止の削減のためにもMulti-AZの利用を検討しましょう。

RDS DB インスタンスのマルチ AZ 配置

【DX】緊急および計画的メンテナンス

DirectConnectは、VPCと利用者の拠点を専用線／閉域網経由で接続するサービスです。

接続は、AWS Direct Connect Location経由で行われます。東京リージョンの場合、EquinixのTY2/TY6/TY8/OS1、アット東京中央データセンター、および台湾のChief Telecom LY経由で接続することが可能です。

Direct Connectでは、頻度は不定期ですがメンテナンスが実施されます。メンテナンスは、事前に連絡がある計画的メンテナンスの場合もあれば、事後連絡の緊急メンテナンスも行われる場合があります。

緊急の場合は 「AWS Direct Connect Emergency Maintenance Notification [AWS Account: XXXXXXXXXXXX]」、計画的な場合は 「AWS Direct Connect Planned Maintenance Notification [AWS Account: XXXXXXXXXXXX]」 という件名でメールが送られます。

Direct Connectを利用する際、一定の可用性を求める場合にはConnectionを冗長化することは基本です（専用線サービスという仕様上、単一コンポーネントの信頼性向上によるダウンタイムの短縮には限界があります）。冗長化していればメンテナンスの影響はほとんどありません。

How should I prepare for maintenance on my Direct Connect connection?

【VPC】VPN接続のメンテナンス

VPCでは、VPCと利用者の拠点をインターネットVPNで接続する機能を提供しています。

VPN接続でも、メンテナンスが発生します。その際には、 「AWS VPN Planned Maintenance Notification [AWS Account: XXXXXXXXXXXX]」 という件名でメールが送られてきます。

VPCのVPN接続では、1つのVPN接続で2つのVPNトンネルを利用でき、冗長化されたトンネルを利用していればメンテナンスの影響はほとんどありません。

【EC2】AMIのリリース

EC2インスタンスを作成する際、AMIを指定しますが、AWSが公式に提供するAMIはそれなりの頻度で更新されます。

例えば、Windows Serverの場合は月例のWindows Updateや緊急アップデートのタイミングから数日後に新しいAMIがリリースされます。これらのリリースは、AWSが所有するSNS Topicを購読することで通知を受けることが可能です。 WindowsおよびAmazon Linuxについては、以下のドキュメントを参照してください。

Windows AMI 通知の受信

Amazon Linux 通知にサブスクライブする

Amazon ECS 対応 AMI の更新の通知をサブスクライブする

Auto Scalingを利用していて、なおかつLaunch Configurationで指定するAMIに公式AMIを利用している場合には、変更を検討しましょう。特に、Windows Serverの場合にはおおよそ過去3-4ヶ月間にリリースされたAMIしか利用できません。 Auto Scalingが機能しない、ということも考えられますので、必要に応じてチェックしましょう。

属人作業

関連サービス	イベント	作業内容
全般	Abuse	レポート内容に応じた作業
SES	エンフォースメント	問題の原因特定／応急措置の実施／恒久対策の実施
Lambda	ランタイムのサポート終了	コードの修正
ElasticBeanstalk	プラットフォームの更新	アプリケーションの動作検証、移行
Shield Advanced	DDoSの検知	攻撃の緩和
ELB	セキュリティポリシーの廃止	（必要に応じて）クライアントの動作検証、設定変更
EC2	OS（Amazon Linux）のサポートライフサイクル	アプリケーションの動作検証、移行

【全般】Abuse Report

利用しているAWSアカウント上で問題のある振る舞いが検知されると、AWSからAbuseレポートがお届けされます。件名は 「Your Amazon EC2 Abuse Report」 などで始まります。

具体的には以下のようなケースです。

EC2上のSMTPサーバーがスパムメールの送信元になっている
DDoS攻撃の攻撃元になっている

このレポートを受け取った場合、内容に応じて即座に対応する必要があります。被害を受けているだけならともかく、加害者になっている場合もあるので、損害賠償請求など訴訟沙汰にならないように迅速に対応しましょう。

How do I report abuse of AWS resources?

【SES】エンフォースメント

SESを利用してメールを送信しているケースでバウンスや苦情が非常に高い場合、AWSからエンフォースメントの知らせが届くことがあります。

Amazon SES のエンフォースメントに関するよくある質問

例えば、送信停止処分の執行猶予状態になると、 「Amazon SES Bounce Probation Lifted for AWS Account XXXXXXXXXXXX」 というメールが届きます。このメールを受け取った場合、送信停止措置が実行されないように問題の解消に着手してください。

もっと言うと、そのような事態にならないように、バウンスレートのモニタリングや送信先の適切なメンテナンスを行うようにシステムや運用を設計しましょう。このあたりに手間をかけたくない場合、専用のSaaSを利用するといいかもしれません。

SendGrid

バウンスメールや迷惑メール報告の対処が簡単にできますか？

【Lambda】ランタイムのサポート終了

現在、AWS Lambdaでは以下のランタイムがサポートされています。

Node.js
4.3.2
6.10.3
Java
8
Python
3.6
2.7
.NET Core
1.0.1
2.0
Go
1.x

Lambda Execution Environment and Available Libraries

サービスがローンチされた当初は、Node.jpの0.1がサポートされていましたが、現在はサポートを終了しています。

Runtime Support Policy

Using the Earlier Node.js Runtime v0.10.42

現時点では具体的なアナウンスは出ていませんが、他のRuntimeでも起こりえます。実際にサポートが終了する場合、その前に速やかに移行を完了させる必要があります。

このようなイベントも含め、対応に時間がかかるような問題はある程度時間的猶予が与えられると思いますが、いつか来る事がわかってるのであれば、可能な範囲で備えておきましょう。

【ElasticBeanstalk】プラットフォームの更新

Elastic Beanstalkでは、定期的に新しいプラットフォームが利用できるようになります。後方互換性の保たれたマイナーバージョンやパッチバージョンアップの場合には自動的に環境を更新することも可能ですが、メジャーバージョンアップや.NET環境の場合には手動での対応が必要になります。詳細な手順は、以下のドキュメントで確認できます。

Elastic Beanstalk 環境のプラットフォームバージョンの更新

マネージドプラットフォーム更新

プラットフォームの更新は、リリースノートで確認することが可能です。

Release Notes

【Shield Advanced】DDoS攻撃の発生

Shelad Advanceでは、DDosの検知および遮断に加え、SoCチームのサポート等を受けることが可能なサービスです。

DDoSを検知すると、 「DDoS threat level elevated to "High" [AWS Shield Advanced Notification] [AWS Account: XXXXXXXXXXXX]」 という件名のメールが送られてきます。

AWSの利用者は、自身で攻撃の緩和に必要な処置を実施できますが、DRT(DDoS Response Team)にWeb ACLの作成を支援してもらうことも可能です。詳細は以下のドキュメントを確認してください。

DDoS 攻撃への対応

それ以前に、設計時にDDoSを想定したアーキテクチャを考えることも重要です。詳細は以下のホワイトペーパーやBlackBeltの資料を参照してください。

AWS Best Practices for DDoS Resiliency

AWS Black Belt Online Seminar 2017 AWS Shield

【ELB】セキュリティポリシーの廃止

ELBでHTTPSを利用する場合、セキュリティポリシーを指定する必要があります。

セキュリティポリシー

Classic Load Balancer での事前定義された SSL セキュリティポリシー

ここで利用されている暗号化の方式などに重大な脆弱性が見つかった場合、セキュリティポリシーが廃止されることが想定されます。その場合、システムを利用できてほしいクライアントで正常に動作するか確認する必要があるでしょう。特に、古いフィーチャーフォンや組み込み系の機器、古いブラウザーで動作させたい場合には注意が必要です。

ELB のセキュリティポリシー変更はブラウザの対応プロトコルを考慮して慎重に

【EC2】OS（Amazon Linux）のサポートライフサイクル

昨年末にAmazon Linux 2のリリースが発表されました。

新世代のAmazon Linux 2 リリース

その際、現行のAmazon Linuxのサポート終了時期も発表されました。 Amazon Linux 2のリリースから2年間、パッチのリリースが行われます。

Q. Will AWS support the current version of Amazon Linux going forward?

Yes – in order to avoid any disruption to your existing applications and to facilitate migration to Amazon Linux 2, AWS will provide regular security updates for Amazon Linux 2017.09 AMI and container image for 2 years after the final LTS build is announced. You can also use all your existing support channels such as AWS Premium Support and Amazon Linux Discussion Forum to continue to submit support requests.

Amazon Linux 2にはsystemdなどのコンポーネントが含まれているので、移行にあたっては十分な検証を行いましょう。

また、AWS特有ではありませんが、その他のOSについてもサポートライフルサイクルを確認し、システムを適切な状態に維持するよう心がけましょう。

Microsoft ライフサイクルポリシー

Ubuntu Server and desktop release end of life

20. What is the support ''end of life'' for each CentOS release?

まとめ

記載の通り、AWSに起因する運用イベントは非常に多岐にわたります。これらを想定することなく運用を開始すると、いざイベントが発生したときに慌てることになりかねません。まずは、どんなイベントが発生するのかしっかり把握しましょう。必要に応じて、AWSサポートやAWSの導入をサポートするパートナーに相談しましょう。例えば、弊社とか弊社とか弊社とか。

ただ、今回まとめてみて改めて感じましたが、AWSの公式ドキュメントには必要なことはほとんど書いてあります。まずはドキュメントをちゃんと読みましょう。

また、一部のイベントは設計で回避したり作業負担を緩和することも可能です（DirectConnectのConnectionを冗長化する、など）。運用負荷を少しでも下げるため、Design for Failureの思想に則って設計および実装しましょう。その際には、Well-Architected FrameworkやOperational Checklistなど参照すると捗ると思います。運用でカバー／残業でカバー、ダメゼッタイ。

AWS Well-Architected

Operational Checklists for AWS

運用するエンジニアの心が、少しでも穏やかになりますように。

現場からは以上です。